home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / applications / 981 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.4 KB
  1. Path: news.mindspring.com!chmood
  2. From: chmood@photobooks.atdc.gatech.edu (Charlie Moody)
  3. Newsgroups: comp.sys.amiga.applications
  4. Subject: [FinalWriter] REPOST:  Modifications & Enhancements, part 1
  5. Date: 21 Jan 1996 06:20:02 GMT
  6. Organization: Photobooks Inc
  7. Message-ID: <4dslui$692@brickbat.mindspring.com>
  8. NNTP-Posting-Host: photobooks.atdc.gatech.edu
  9. X-Newsreader: TIN [version 1.2 PL2]
  10.  
  11. With apologies to the group, I've discovered that only the first fourth 
  12. of my text got posted.  Therefore, I'm taking the liberty of posting the 
  13. entire thing, in four parts.
  14.  
  15.  
  16. FinalWriter - release 2.1:    Request for Modifications and Enhancements
  17.  
  18.  
  19.  
  20.  
  21.  
  22. Let me begin this by thanking you for producing a text engine for the Amiga that
  23. is worthy of being improved.  Despite early frustrations, inadequate (tho
  24. attractive) documentation, and the ongoing confusion of trying to intuit your
  25. implementation of various features, my estimate of FW's value has gone up:
  26. especially since I received the 2.1 upgrade.  The addition of so simple a
  27. feature as the paragraph strip has dramatically increased FW ef- fectiveness for
  28. me  (why do you call it a paragraph strip?  I think I'd call it a text strip.)
  29.  
  30.  
  31.  
  32. I've spent many hours compiling and refining the suggestions here, and in the
  33. process, I've arrived at a few fundamental criticisms of FW's operation and (in
  34. places) design.  As a retired software jock, I've found myself putting on my
  35. design hat in doing so.  I hope that you'll give serious consideration to my
  36. suggestions for enhancements, as I believe they can lift FW to the top rank of
  37. word processors regardless of platform.
  38.  
  39.  
  40.  
  41. My overall observations?  First, that FW is slow.  Opening at startup, opening a
  42. new window (opening "Untitled", then loading the chosen document), changing from
  43. one window to another, synchronous printing, changing from arrow-pointer to
  44. insertion-pointer ('][') - waiting for these is annoying and distracting. The
  45. culprit often seems to be multiple unnecessary screen redraws; surely you can
  46. easily check to see if a document uses custom palettes, strips, etc., and then
  47. draw the window accordingly, once!  (If each doc has its own prefs structure,
  48. this should be easy....)
  49.  
  50.  
  51. Program preferences and document defaults strike me as confusing, illogical and
  52. lacking in power & features.  Of all the areas I feel need improvement, this
  53. area of program and document control (and the opportunities to change these
  54. things that are scattered throughout the program) stands out as being in the
  55. greatest need.    Accordingly, I'll discuss this area in some detail below.
  56.  
  57.  
  58. It may be that making such changes as I propose here will require major design
  59. revision:  I certainly hope not;  and yet, such possibility exists in any
  60. project involving ongoing development, and there is no reason why FW3 couldn't
  61. set a new standard in w/p design & implementation.  I hope it will!
  62.  
  63.  
  64.  
  65. BUGS
  66.  
  67. Menu selections only take effect if the pointer is showing the '][' image during
  68. the selection.    Menu access should be enabled regardless of pointer type. As
  69. mentioned above, the time required for the pointer image to change is excessive:
  70. please find a way to speed it up.
  71.  
  72. Hyphenation:  terms, such as 'self-defense', which contain suppled hyphens, are
  73. not handled correctly.    In the document I'm working with (in the other window),
  74. 'self-defense' is treated as one word, and it is bumped to the next line as a
  75. whole;    attempting to defeat this by typing 'self- defense' (breaking it into
  76. two words) results in 'self- def' at the end of one line, and 'ense' at the
  77. beginning of the next.    This should never happen!  Words containing supplied
  78. hyphens should break following the supplied hyphen. Strings containing slash
  79. characters ('/') should treat these as supplied hyphens, per above, for
  80. correctly breaking pathnames and other compound constructions.
  81.  
  82. Top margins are not retained during final printing.  I've enclosed a sample
  83. page displaying this, encase you haven't seen it.
  84.  
  85.  
  86.  
  87. SHORTCOMINGS THAT COULD ALMOST COUNT AS BUGS
  88.  
  89. A flashing cursor option should be available, as well as cursor color selection.
  90.  
  91. FW will abort an Open-Document request if the user specifies a file name that
  92. doesn't exist in the selected drawer.  FW should create the file, then open it -
  93. not just bail out w/ a screen flash!
  94.  
  95. ASCII files should be treated as ASCII ASCII files are automaticaaly converted
  96. to FW format.  This should be made explicit by requiring the user to import as,
  97. or export to, a FinalWriter file.  Similarly, exporting as ASCII should allow
  98. exported lines to wrap as one would expect, and avoid hard EOLs.  I wrote this
  99. file in FW 2.1 & FW 3.0, exported it to ASCII, and am adding this line during my
  100. cleaning-up of the file.
  101.  
  102. Keyboard control for moving from word to word requires two hands:  this should
  103. be at least possible as a one-handed operation.  I recommend you swap control
  104. keys for this function w/ those now used for block selection:
  105.  
  106.     shift-arrow      =    move word-to-word or paragraph-to-paragraph
  107.     ctrl-arrow       =    highlight characters / line fragments
  108.     ctrl-shift-arrow =    highlight words / whole lines
  109.  
  110. Draft-mode printing doesn't preserve general formatting attributes such as
  111. bolding, centering, italics, underlining, margins, etc.  As a result, draft
  112. copies can't be used to check and correct formatting inconsistencies. This
  113. drastically reduces the value of having a draft copy in the first place.
  114. Draft-mode printing should preserve all standard formatting attributes via the
  115. standard Amiga printer commands.
  116.